The present invention relates to a method for installing a security-relevant portion of an application in a security element of a portable terminal, a corresponding security element, as well as a portable terminal having such a security element.
The functionality of portable terminals, such as for example of mobile communication terminals, smart phones, tablets and the like, can be extended in known fashion by installing software functionalities, so-called applications or “apps”. Various ones of these applications therein serve for uses where also security-relevant data are comprised and/or processed. Security-relevant data can be for example personal data of a user of the terminal which are to be kept secret, such as for example biometric data, or data employed for making financial transactions, such as for example credit card number, account data, content of electronic purses, cryptographic keys, etc. In the context of the present in invention, a security-relevant portion of an application is understood as both security-relevant data comprised or processed by the application and (partial) functionalities of the application which serve for processing these data.
It is known to protect such security-relevant portions of an application against manipulation and unauthorized access by storing or installing these parts in the terminal in a specially secured area.
Security elements that can be integrated in a terminal or are permanently incorporated therein represent suitable secured areas. Security elements which can be removably integrated are for example SIM/UICC mobile communication cards, secure multimedia cards or the like. For example embedded SIM/UICC mobile communication cards, TPMs (trusted platform modules) or NFC modules can serve as security elements which are permanently incorporated in the terminal. Finally, also secure execution environments within a specific hardware architecture of the terminal, for example within an ARM TrustZone architecture, can serve as security elements, such as for example a “trusted execution environment” according to the “Global Platform” specification.
An installation of data and/or applications or portions of applications in such a security element is cryptographically secured as a rule. Increasingly, security-relevant portions of applications installed on portable terminals are carried out with the aid of trustworthy instances, so-called “trusted service managers” (hereinafter referred to as TSM). These take the security-relevant portions as service providers, and carry out the installation process, i.e. the secured installation of the portions in the security element. In the following the formulation will be used in this context according to which the TSM “administrates” the security element. Prior to the step of installation, cryptographic keys are exchanged between the TSM and the institution making available the application, for example a bank in the case of a payment application to be personalized, and are introduced in the security element in secured fashion. By means of these keys the installation process can be secured cryptographically.
It must be noted that a security element of the above-described type can comprise a plurality of secured areas. This means that for example a SIM card as a physical security element can comprise a plurality of secured areas in one memory of the card. In particular, these secured areas can be present in the form of so-called “security domains” according to the Global Platform specification (cf. e.g. Global Platform, Card Specification, version 2.2). Such a “security domain” as a rule is allocated to a predetermined external instance, for example the issuer of the data carrier, a network operator, an application provider or the like. This instance will be referred to as “owner” of the “security domain” in the following. In analogous fashion, in the following reference will be made to an “owner” of a security element when the respective instance is to be indicated to which the security element is allocated. The owner of the security element is responsible in particular for the key architecture of the security element.
A “security domain” represents a privileged application, which has its own cryptographic key architecture. This makes it possible in particular to install data and application in a secure fashion in the area of a memory of the respective data carrier or security module that is administrated by the “security domain”. “Security domains” can be present on a security element in hierarchically arranged fashion. In particular, different “security domains” can be administrated by different TSMs on a physical security element, for example a SIM card, in the above-described fashion for installing security-relevant portions of an application.
It is a disadvantage of the described procedure for installing security-relevant portions of an application in a security element that a developer who programs applications and offers these for downloading to a portable terminal via an application provider, for example via a so-called “app store”, can practically not offer applications with security-relevant portions when this approach is taken. The free development of applications with security-relevant portions is substantially limited and impeded thereby.
This is applicable for the reason that an installation of security-relevant portions in a security element of the terminal has been possible so far only in cooperation with the respective TSM of the security element. However, this TSM is usually unknown to the developer, in particular since a multiplicity of TSMs exist today. Further, different users of terminals can provide respectively different TSMs for administrating the corresponding security elements for the purpose of administrating respectively one security element that is fundamentally provided for installing the same application and/or its security-relevant portion. Finally, a developer of an application does not have access and cannot influence the key architecture of a security element of a terminal of any user wishing to acquire and install the application via an “app store”, i.e. without direct interaction with the developer. This means that even if the developer knew and could contact the responsible TSM in the concrete case, no installation of data could take place on the security element. The developer could exchange corresponding cryptographic keys with the TSM, but it would not be possible for the developer to incorporate these keys in the security element, since he has no access to such a security element.